As described in https://hackmd.io/@tvpl/H1whErCI3, introduce a set of capabilities that will:
1) allow providers to rate limit (especially fully limit, ie block) users
2) allow providers to get information about subscriptions and consumers

TODO
-[] write tests for capabilities (need to pick @Gozala's brain)
-[] implement in-memory RateLimitsStorage
-[] use it to write `upload-api` tests
-[] move capabilities spec from hackmd to https://github.com/web3-storage/w3up/blob/main/spec/capabilities.md
-[] port 0eea3d1 and d230033 to this commit

originally implemented in #801, this allows us to block space allocation for a particular space or account creation for a particular email or domain

mostly just cargo-culting the existing type setups, but basing these types on the designs proposed in https://hackmd.io/@tvpl/H1whErCI3

also update existing Consumer.has types to match our normal patterns

it really wasn't happy with getCustomer potentially returning `null` and I think that should use a `Ucanto.Failure` anyway so I elected to make a backwards-incompatible change here since I think this work will merit a breaking change anyway

this eliminates the specter of partial failure

Remove it from the interface - I thought that IN queries would be supported by Dynamo but they aren't. I was already on the fence about this interface method and this pushed me into the "not worth it" camp.

I thought we were doing this, but the implementation of `allocateSpace` in the `AccessVerifier` never actually called into `Space.allocate`, it just used `Space.info` to make sure the space existed, which, until now, fair!

I'm not sure this is the right way to call the `Space.allocate` provider - maybe it would be better to invoke and execute the actual capability rather than just calling the provider function?

this gets basic testing in place for the new rate limit capability handlers

the test implementations are a bit wordier and boilerplate-inclined than I'm strictly happy with, but I don't have any easy plans to clean them up - need to think and prototype a little

The AccessVerifier was an artifact of the dual-service architecture we had previously, and its implementation in tests
both hid bugs and made it more difficult to test the whole system. I've removed it and gotten the tests running!

so we can use it in w3infra

id is used more consistently in w3infra tests and they are identical

Co-authored-by: Irakli Gozalishvili <[email protected]>

Co-authored-by: Irakli Gozalishvili <[email protected]>

Co-authored-by: Irakli Gozalishvili <[email protected]>

ensure callers can't change subject, rate or id constraints

we err on the side of denying a user the ability to authorize or provision a space - they can retry and we really don't want to let people do things unless we're sure they're allowed to

per feedback from @Gozala, move to a style where we always return an `{ok: {}}` result if there is no rate limit above a given threshold.

use this instead of an explicit "block" checker

per feedback from @Gozala, explain the reasoning behind having a separate, opaque identifier for rate limits.

this ensures people can't upload to a blocked space, and makes it more consistent.

this also gets rid of the `size` parameter in `space/allocate` because:

a) we weren't using it for anything
b) we don't have size information in `upload/add`

I think we'll want to add this back in later, possibly as an optional parameter that triggers a check against provisioned allocation, or we'll want to split space/allocate into two capabilities.